BBS Toolkit/BBS Toolkit.iso/gt_power/gth035.zip/ROUTING.HLP

Text File | 1990-06-30 | 17KB | 503 lines

╔═════════╦════════════════════════════════════════════════════════════
║ GT-HELP ║ ROUTING.BBS - the standard routing file.
╚═════════╩════════════════════════════════════════════════════════════

    The routing file is used to prevent you from placing *direct* calls to
    every node that you have mail for.

    In theory, you don't need a routing file - if you don't have one, then
    you simply call everybody in the nodelist direct.

    In practice, almost everybody has one.  Its usually cheaper and more
    efficient to work through the local hub.  Unless of course you *are*
    the local hub - in which case you *certainly* need a routing file.


┌──────────────────────────────────────────────────────────────────┐
│ Simple Setup - all mail via a STATIC hub (ie, you call it daily) │
└──────────────────────────────────────────────────────────────────┘

    PREFIXES LOCAL(+) DISTANT(*)
    END
    ;
    ;   As your hub is probably going to match the LOCAL prefix, it may be
    ;   useful to set the DISTANT prefix (defined in the ALT-I screen, "*" in
    ;   this case) to and invalid dialcode, which will prevent it from dialling
    ;   Outer Mongolia if for some reason mail does not get consolidated properly.
    ;
    ;   (This will however prevent you placing .DX calls to other nodes, so
    ;   you may wish to remove it after you are sure all is OK).
    ;
    ;   See Prefixes below for more information.
    ;
    ;
    OUTBOUND NODES
        050/001
    END
    ;
    ; 050/001 is listed as outbound to make sure I call it every day, even
    ; if I have no mail to go there.
    ;
    ;
    BAG CONSOLIDATION
        050/001
    END
    ;
    ;   This creates a G bag containing all 050/001 mail (faster than
    ;   separate bags)
    ;
    ;
    ROUTING INSTRUCTIONS
        FORWARD 001-899/000-899 -> 050/001
    END
    ;
    ;
    Everything to my hub - can't get much simpler than that.
    ;


┌────────────────────────────────────────────────────────────────────┐
│ Simple Setup - all mail via an ACTIVE hub (ie, it calls you daily) │
└────────────────────────────────────────────────────────────────────┘

    The same as the above, but *delete* the OUTBOUND NODES section and
    replace it with

    INBOUND NODES
       050/001
    END
    ;
    ;   Don't call this node, even if there is mail for it.
    ;


┌─────────────────────────────────────────────┐
│ Handling echos which somebody else sponsors │
└─────────────────────────────────────────────┘

    For this example, lets assume the echos you need are :

            E38/013     Northumberland Widgets
            E42/293     Apathy Anonymous

    a)  Make sure that your hub is sending you mail in G bags.

    b)  Create directories for the message bases, add entries in GTMDIR.BBS
        for the echos :

            P ^D:\NORWID      Northumberland Widgets (E38/013)
            R ^E:\APATHY      Apathy Anonymous       (E42/293)

    c)  Add a message distribution section to your ROUTING.BBS :

    MESSAGE DISTRIBUTION
        E38/013 -> D:\NORWID    ,Northumberland_Widgets
        E42/293 -> E:\APATHY    ,Apathy_Anonymous
    END

    d)  Add the "upstream" information to the ROUTING section:

    ROUTING INSTRUCTIONS
        FORWARD 001-899/000-899 -> 050/001
        ACCEPT E38/013 -> 050/001
        ACCEPT E42/293 -> 050/001
    END

    e)  Send a netmail message to your hub containing the request commands:

    .GM E38/013
    .GM E42/293

    f)  Ignore all references in documents to a REQUEST ECHOMAIL
        CONFERENCES section.  Unless the hub you are collecting it from is
        running a very old version of the netmail software, the bag
        consolidation method is a much more efficient way of collecting
        echos.


┌──────────────────────────────────┐
│ Handling echos which YOU sponsor │
└──────────────────────────────────┘

    a)  Obtain an echo id and its CRC from your echo coordinator.

        For this example, lets assume this is :

            E27/123     Brontosaurus Spotting   (CRC 2468-2ABC)

    b)  Create directories for the message base, add entries in GTMDIR.BBS
        for the echo :

            F ^D:\BRONTO      Brontosaurus Spotting  (E27/123)

    b)  Add a message distribution section to your ROUTING.BBS :

    MESSAGE DISTRIBUTION
        E38/013 -> D:\NORWID    ,Northumberland_Widgets
        E42/293 -> E:\APATHY    ,Apathy_Anonymous
        E27/123 -> D:\BRONTOS   ,Bronto_Spot
    END


    d)  Add the CRC information to the ROUTING section:

    ROUTING INSTRUCTIONS
        FORWARD 001-899/000-899 -> 050/001
        ACCEPT E38/013 -> 050/001
        ACCEPT E42/293 -> 050/001
        ACCEPT E27/123 $2468-2ABC
    END

    e)  Ensure that you are consolidating mail to the intended
        destination(s). You can either add the echo line to the
        consolidation section :

    BAG CONSOLIDATION
        050/001
            E27/123
    END

        or have the other node put in a .GM message for the echo.


┌──────────────────┐
│ Handling Netmail │
└──────────────────┘

    Apart from the ROUTING as mentioned above and described in more detail
    later, the routing.bbs is not normally concerned with netmail.

    The netmail area is defined by the ~ prefix in GTMDIR.BBS (described in
    another menu) and you should set up at least one such message area.



                     ┌────────────────────────┐
                     │ The Sections in detail │
                     └────────────────────────┘
                 All sections are optional, and can
                  simply be omitted if not needed.

     Note that all sections begin with a heading and end with END.
                The order of sections is unimportant.


┌──────────┐
│ Prefixes │
└──────────┘

    Usually, a prefix entry is needed to distinguish between local and long
    distance numbers.  Typically :

        PREFIXES LOCAL(+) DISTANT(*)
        END

    This specifies that:

    a)  "local" numbers (those in the nodelist that begin with the number
        specified in AREA in my SCHEDULE.BBS) should be called by:

        i)      dialling the standard prefix, followed by whatever is
                configured as prefix +, both as defined in GT's ALT-I
                screen.

        ii)     *stripping off* the AREA code and dialling the balance of
                the number from the nodelist.

        iii)    dialling the standard suffix as configured by ALT-I.

    b)  all other numbers should be called by:

        i)      dialling the standard prefix, followed by whatever I
                configured as prefix *, both as defined in GT's ALT-I
                screen.

        ii)     dialling the *full* number from the nodelist.

        iii)    dialling the standard suffix as configured by ALT-I.

    If you are outside USA, you will probably need to segregate numbers
    into at least THREE types.  GT only provides two, which means that you
    will not be able to call all possible destinations during the same
    mailslot.

    The easiest answer is to put most of the mail through a hub system.
    Or, if you are the hub, to set up additional ROUTING files and operate
    more than one mailslot.


┌────────────────────────────┐
│ Inbound and Outbound Nodes │
└────────────────────────────┘

    By default, GT will CALL those nodes which it has mail for.  It will
    not call other nodes, nor will it call nodes whose mail is being
    FORWARDED via another node (unless there is a DX message for that
    node).

    If there are nodes you wish to call even when though you have NO mail
    for it, then you specify them as OUTBOUND.  If working through a hub,
    you would probably do that to ensure you place a daily call to pick up
    any mail for you.

    If there are nodes you do not wish to call even when you do have mail
    for them, then you specify them as INBOUND.  Usually it only makes
    sense to do that if they are going to call you regularly.  It is not
    necessary to do that for nodes which are defined on the left side of an
    ACCEPT or FORWARD statement.

    Examples:

        INBOUND NODES
           050/030
        END
        OUTBOUND NODES
           050/001
           050/022
        END


┌──────────────────────┐
│ Routing Instructions │
└──────────────────────┘

    Types of instructions:

        FORWARD 003-008/000-899 -> 050/001

            All mail for all nodes (ie nodes 0 to 899) in nets 3 to 8
            should be forwarded to 050/001

        ACCEPT 020-020/000-899 -> 050/001

            As well as forwarding any of your own mail to the specified
            nodes, you will also ACCEPT such mail from other sources and
            pass it on.

        ACCEPT E34/246 $xxxx-yyyy

            An accept statement for an echo you sponsor, where xxxx-yyyy is
            your echo CRC.

        ACCEPT E30/000-999 -> 050/001

            A general 'upstream' routing for echo bags in a particular
            series.  Identifies where messages you enter in those echos
            should be routed on their way to the sponsor.  Generally
            expected to be an ACCEPT rather than a FORWARD, since others
            should be able to route their upstream echo bags via you.

            Note:   It is wise to check that your next destination has an
                    onward routing for any echos not sponsored there.

                    If the range overlaps an echo which you sponsor, be
                    sure the sponsored echo is listed first.


┌───────────────────┐
│ Bag Consolidation │
└───────────────────┘

    In general, you should only include nodes that you connect with
    directly in the consolidate list.  Indirect connections automatically
    receive indirect consolidation, according to the ACCEPT/FORWARD
    definitions in the routing section.

        BAG CONSOLIDATION
            050/001,Q
                E27/123
            050/022,QZ
        END

    The ,Q indicates that the first node can handle Q bags.  If a Q bag
    exists for E27/123 it will be sent, otherwise an E bag will be used.

    Note:   Although E27/123 is shown listed here, it is usually better to
            control echo consolidation either by the caller sending a .GM
            request or using MEDIT.  The problem is that putting it in the
            routing file is a NON-reversible process - when you take it
            out, the echo continues to be consolidated - which makes for
            confusion.

    The ,QZ indicates that the second node has also requested Zipped Gbags.
    (default is to use PKARC).  Use the zip option only if the recipient
    requests it, it makes larger G bags.


┌─────────┐
│ Pursuit │
└─────────┘

    Pursuit is a system available only to US users in certain areas.  Its
    format is :

        PURSUIT
            ACCESS=
            USERID=
            PASSWORD=
            CITIES
                201,NJNEW-Newark
                216,OHCLV-Cleveland
                202,DCWAS-Washington
                305,FLMIA-Miami
                206,WASEA-Seattle

                All 33 (???) cities should be included.
        END


┌───────────────┐
│ Long Distance │
└───────────────┘

    This section is used to identify individual nodes, or a range of nodes
    within a particular net, whose telephone numbers match the AREA entry
    in SCHEDULE.BBS but should nevertheles use the Long Distance prefix (as
    defined in the Prefixes section) rather than the local one.

        LONG DISTANCE
            001/002-005
            002/020-022
        END


┌──────────────────┐
│ Pickup Overrides │
└──────────────────┘

    When MDRIV calls a number in your own net, it delivers mail and also
    requests to pick up any mail for you.  When it calls a number outside
    your own net it will only *deliver* mail - unless the destination
    matches an entry in the pickup list.

        PICKUP OVERRIDES
            003/004-005
        END


┌─────────────────┐
│ Request Echo... │
└─────────────────┘

    Echos now generally travel in consolidated bags -- so for most purposes
    you can *ignore* this section.

    You should certainly not list any echo here which is also being
    delivered in a consolidated bag.

    If you *do* need to use this section, eg if you are picking it up
    direct from a board with an old version of netmail, its format is :

        REQUEST ECHOMAIL
            E00/002
            E00/008
        END

    Such a request has to be used in conjunction with an ACCEPT statement
    in the routing section, eg

        ACCEPT E00/002 -> 050/001

    defining 050/001 as the next upstream node, from which the distributed
    echo bags are collected.


┌──────────────────────┐
│ Message Distribution │
└──────────────────────┘

    Echos which you handle - whether as sponsor or subscriber - should
    normally have an entry here.

        MESSAGE DISTRIBUTION
            E38/013 -> D:\NORWID    ,Northumberland_Widgets
            E42/293 -> E:\APATHY    ,Apathy_Anonymous
            E51/127 -> D:\XXXX      ;Jam_Recipes (Topsecret)
        END

    The information after the comma is optional and purely for
    identification.  It is used as an archive comment when zipping the
    messages and it is reported in response to a .GL request.

    In greater detail :

       ┌──────────────────────────────────── Echo ID
       │     ┌──────────────────────────────── Keep bags for 10 days
       │     │ ┌──────────────────────────────── Generate Q bags
       │     │ │       ┌────────────────────────── Message base path
       │     │ │       │                         ┌── Comma to include in .GL
       │     │ │       │     ┌───────────────────┴── or Semicolon to exclude
       │     │ │       │     │       ┌────────────────── Comment
       │     │ │       │     │       │          ┌───────── Optional Password
    ───┴─── ─┘ │    ───┴───  │ ──────┴──── ─────┴─────
    E51/127,10,Q -> D:\XXXX  ; Jam_Recipes (Topsecret)

    The Q option is appropriate only on echos which you sponsor.



    A semicolon in place of a comma omits that echo from the .GL listing.
    A word enclosed in parentheses (round brackets) acts as an encryption
    password for the echo.

    Note:   A common error is putting a comment like (new) in parentheses
            against a description - the echo gets unintentionally encrypted
            using the comment as a password.


    If you are a hub, you may be collecting echos which do not need to be
    distributed into a local message base.  Such echos do not need an entry
    in the message distribution section.


DISTRIBUTING NETMAIL
--------------------

    Normally, netmail does not need to have a distribution entry.  In the
    absence of instructions to the contrary, netmail will be distributed to
    the first message base listed in GTMDIR.BBS with a ~ prefix.

    If you have a lot of netmail from particular nets or nodes, then it is
    possible to dedicate an area specifically to receive netmail from those
    nodes :

    a)  set up an additional message area in GTMDIR.BBS, ensuring that it
        has the ~ prefix and is listed *after* your main netmail area.

    b)  add an entry in the MESSAGE DISTRIBUTION section such as

            050/001-999 -> D:\LOCALNET

        which would have the effect of distributing messages from any node
        in net 050 to the specified message base.


┌────────────────┐
│ Echomail Hours │
└────────────────┘

    Used to restrict the time in which echo requests can be processed.  An
    exception to the normal section rules, this has no heading or end.

        ECHOMAIL HOURS 0400-0500

    Echomail now mostly travels in consolidated bags, which are exempt from
    the restriction, so this statement is virtually obsolete.


┌────────────────┐
│ Excluded Nodes │
└────────────────┘

    Normally you would not have any requirement to exclude any node, but
    this section can be used to prevent certain nodes from calling you
    direct.

        EXCLUDED NODES
            001/534
            002/467
        END